Modern programming languages such as Java and C# use permission checks as an access control mechanism to protect security-sensitive entities from public access. This access control is typically enforced dynamically by examining the runtime call-stack to check whether every caller on the stack has the required permissions. This mechanism ensures that when untrusted code invokes trusted code, the untrusted code cannot indirectly access items via the trusted code.
However, in certain situations untrusted code does need limited access to the restricted information. To enable this access, some programming languages provide a mechanism to permit untrusted code to access restricted entities in a “safe manner” (e.g., via a doPrivileged( ) method in Java) that effectively allows untrusted code to invoke a trusted intermediary that accesses the restricted entity on behalf of the untrusted code. This results in elevation of privileges for the untrusted code via the intermediary. Both the permission checks and privilege elevations are specified programmatically and there is no formal specification of the restricted entities or privilege elevations. When design intent is not documented either formally or informally, it is easy to lose sight of the implicit security requirements while revising the code. Hence the programmer is solely responsible for the enforcement of the desired, but not explicitly specified, security properties. This could potentially lead to security weaknesses and vulnerabilities. Detection of security-related programming errors becomes difficult as there is no clear specification of acceptable and unacceptable program behavior. The situation is even more difficult for software libraries which are expected to enforce security for all possible programs (which are unknown) that use the library. Currently there is no existing tool that can automatically identify security-sensitive entities.